<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Decompiler Options</title>
<link rel="stylesheet" type="text/css" href="help/shared/DefaultStyle.css">
<link rel="stylesheet" type="text/css" href="../../shared/languages.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.79.1">
<link rel="home" href="Decompiler.html" title="Decompiler">
<link rel="up" href="Decompiler.html" title="Decompiler">
<link rel="prev" href="DecompilerAnnotations.html" title="Program Annotations Affecting the Decompiler">
<link rel="next" href="DecompilerWindow.html" title="Decompiler Window">
</head>
<body><div class="chapter">
<div class="titlepage"><div><div><h1 class="title">
<a name="DecompilerOptions"></a>Decompiler Options</h1></div></div></div>
  
<div class="simplesect">
<div class="titlepage"></div>
  <p>
    This page lists configuration options that explicitly affect the behavior of the Decompiler or
    its output, independent of the code that is being decompiled. The bulk of these options are
    accessible by selecting the Code Browser menu
    </p>
<div class="informalexample">
      <span class="bold"><strong>Edit -&gt; Tool Options...</strong></span>
    </div>
<p>
    and then picking the <span class="emphasis"><em>Decompiler</em></span> folder. The options are associated
    with the particular Code Browser or other tool being used and will apply to decompilation of any Program
    being analyzed by that tool. There are three categories of options, which are listed by clicking either on the
    <span class="emphasis"><em>Decompiler</em></span> folder or one of its two subsections.
    </p>
<div class="informalexample">
      <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: none; ">
<li class="listitem" style="list-style-type: none">
	  <span class="guiicon">
	    <span class="inlinemediaobject"><img src="images/openFolder.png" width="25" height="17"></span>
	  </span><span class="emphasis"><em>Decompiler</em></span> - lists <a class="xref" href="DecompilerOptions.html#GeneralOptions" title="General Options">General Options</a> that affect the engine behavior.
	</li>
<li class="listitem" style="list-style-type: none">
	   <span class="guiicon">
	    <span class="inlinemediaobject"><img src="images/document-properties.png" width="16" height="16"></span>
	  </span> <span class="emphasis"><em>Analysis</em></span> - lists <a class="xref" href="DecompilerOptions.html#AnalysisOptions" title="Analysis Options">Analysis Options</a> that affect the Decompiler's transformation process.
	</li>
<li class="listitem" style="list-style-type: none">
	   <span class="guiicon">
	    <span class="inlinemediaobject"><img src="images/document-properties.png" width="16" height="16"></span>
	  </span> <span class="emphasis"><em>Display</em></span> - lists <a class="xref" href="DecompilerOptions.html#DisplayOptions" title="Display Options">Display Options</a> that affect the final presentation of Decompiler output.
	</li>
</ul></div>
    </div>
<p>
  </p>
  <p>
    Options that are specific to the particular Program being analyzed are accessed by
    selecting the Code Browser menu
    </p>
<div class="informalexample">
      <span class="bold"><strong>Edit -&gt; Options for &lt;program&gt;...</strong></span>.
    </div>
<p>
    Picking the <span class="emphasis"><em>Decompiler</em></span> section shows <a class="xref" href="DecompilerOptions.html#ProgramOptions" title="Program Options">Program Options</a>
    that only affect the Decompiler.  Picking the <a class="xref" href="DecompilerOptions.html#ExtensionOptions" title="Specification Extensions">Specification Extensions</a> section
    shows a table of the available prototype models, call-fixups, and callother-fixups. These
    affect more than just the Decompiler but are also documented here.
  </p>
</div>
<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="GeneralOptions"></a>General Options</h2></div></div></div>
  
  <p>
    These options govern what resources are available to the Plug-in and the Decompiler engine but do
    not affect how analysis is performed or results are displayed.
  </p>
  <p>
    </p>
<div class="informalexample">
    <div class="variablelist"><dl class="variablelist">
<dt>
<a name="GeneralCacheSize"></a><span class="term"><span class="bold"><strong>Cache Size (Functions)</strong></span></span>
</dt>
<dd>
	<p>
	  Producing decompilation results for a single function can be computationally intensive.
	  This option specifies the number of functions whose decompilation results
	  can be cached simultaneously. When navigating to a function that
	  has been recently cached, as when navigating back and forth between a few functions,
	  a new decompilation is not triggered.
	</p>
      </dd>
<dt>
<a name="GeneralMaxPayload"></a><span class="term"><span class="bold"><strong>Decompiler Max-Payload (MBytes)</strong></span></span>
</dt>
<dd>
	<p>
	  This option limits the number of bytes that can be produced by the Decompiler process as output
	  when decompiling a single function. A payload includes the actual characters to be displayed in
	  the window, additional token markup, symbol information, and other details of the underlying
	  syntax tree. The limit is specified in megabytes of data. If the limit is exceeded for a single
	  function, decompilation is aborted for that function, and an error message
	  "Decompiler results exceeded payload limit ..." is displayed.
	</p>
      </dd>
<dt>
<a name="GeneralTimeout"></a><span class="term"><span class="bold"><strong>Decompiler Timeout (seconds)</strong></span></span>
</dt>
<dd>
	<p>
	  This option sets an upper limit on the number of seconds the Decompiler spends attempting
	  to analyze one function before aborting.
	  It is currently <span class="bold"><strong>not</strong></span> enforced for a Decompiler
	  window.  Instead it applies to the DecompilerSwitchAnalyzer, the <code class="code">analyzeHeadless</code> command, scripts, and other
	  plug-ins that make use of the Decompiler service.
	</p>
      </dd>
<dt>
<a name="GeneralMaxInstruction"></a><span class="term"><span class="bold"><strong>Max Instructions per Function</strong></span></span>
</dt>
<dd>
    <p>
      This option sets a maximum number of machine instructions that the Decompiler will attempt
      to analyze for a single function, as a safeguard against analyzing a long sequence
      of zeroes or other constant data. The Decompiler will quickly throw an exception if it
      traces control flow into more than the indicated number of instructions.
    </p>
      </dd>
<dt>
<a name="GeneralMaxJumptable"></a><span class="term"><span class="bold"><strong>Max Entries per Jumptable</strong></span></span>
</dt>
<dd>
	<p>
	  This option sets the maximum number of entries (addresses) that the Decompiler can
	  recover from analyzing a single jumptable. This serves as a sanity check that the recovered
	  dimensions of a jumptable are reasonable and places an upper limit on the sheer number
	  of addresses the Decompiler is willing to trace from a single indirect jump.
	</p>
      </dd>
</dl></div>
    </div>
<p>
  </p>
</div>

<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="AnalysisOptions"></a>Analysis Options</h2></div></div></div>
  
  <p>
    These options directly affect how the Decompiler performs its analysis, either by
    toggling specific analysis passes or changing how it treats various annotations.
  </p>
  <p>
    </p>
<div class="informalexample">
    <div class="variablelist"><dl class="variablelist">
<dt>
<a name="AnalysisAliasBlocking"></a><span class="term"><span class="bold"><strong>Alias Blocking</strong></span></span>
</dt>
<dd>
	<p>
	  When deciding if an individual stack location has become dead, the Decompiler
	  must consider <span class="emphasis"><em>aliases</em></span>, pointers onto the stack that could
	  be used to modify the location within a called function.  One strong heuristic the Decompiler
	  uses is: if the user has explicitly created a variable on the stack between the
	  base location referenced by the pointer and the individual stack location, then
	  the Decompiler can assume that the pointer is not an alias of the stack location.
	  The alias is <span class="emphasis"><em>blocked</em></span> by the explicit variable.
	  However, if the user's explicit variable is labeling something that isn't
	  really an explicit variable, like a field within a larger structure, for instance,
	  the Decompiler may incorrectly consider the stack location as dead and start removing
	  live code.
	</p>
	<p>
	  In order to support the exploratory labeling of stack locations, the user can use this
	  setting to specify what data-types should be considered blocking. The four options are:
          </p>
<div class="informalexample">
            <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>None</strong></span> - No data-type is considered blocking</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Structures</strong></span> - Only structures are blocking</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Structures and Arrays</strong></span> - Only structures and arrays are blocking</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>All Data-types</strong></span> - All data-types are blocking</li>
</ul></div>
	  </div>
<p>
	  Selecting <span class="emphasis"><em>None</em></span> is the equivalent of turning off the heuristic. Selecting anything
	  except <span class="emphasis"><em>All Data-types</em></span> allows users to safely label small variables without
	  knowing immediately if the stack location is part of a larger structure or array.
	</p>
      </dd>
<dt>
<a name="AnalysisUnreachable"></a><span class="term"><span class="bold"><strong>Eliminate unreachable code</strong></span></span>
</dt>
<dd>
	<p>
	  When toggled <span class="emphasis"><em>on</em></span>, the Decompiler eliminates code that it
	  considers unreachable.  This usually happens when, due to constant propagation and other
	  analysis, the Decompiler decides that a boolean value controlling a conditional branch can
	  only take one possible value and removes the branch corresponding to the other value. Toggling
	  this to <span class="emphasis"><em>off</em></span> lets the user see the dead code, which is typically demarcated
	  by the control-flow structure:
	  </p>
<div class="informalexample">
	    <code class="code">if (false) { ... }</code>
	  </div>
<p>
	</p>
      </dd>
<dt>
<a name="AnalysisIgnoreUnimplemented"></a><span class="term"><span class="bold"><strong>Ignore unimplemented instructions</strong></span></span>
</dt>
<dd>
	<p>
	  When toggled <span class="emphasis"><em>on</em></span>, the Decompiler treats instructions whose semantics
	  have been formally marked <span class="bold"><strong>unimplemented</strong></span> as if they do
	  nothing (no operation). Crucially, control flow falls through to the next instruction.
	  In this case, the Decompiler inserts the warning "Control flow ignored unimplemented
	  instructions" as a comment in the function header, but the exact point at which
	  instruction was ignored may not be clear.
	  If this option is toggled <span class="emphasis"><em>off</em></span>, the Decompiler inserts the built-in
	  function <code class="code">halt_unimplemented()</code> at the point of the unimplemented instruction, and
	  control flow does not fall through.
	</p>
      </dd>
<dt>
<a name="AnalysisInferConstants"></a><span class="term"><span class="bold"><strong>Infer constant pointers</strong></span></span>
</dt>
<dd>
	<p>
	  When toggled <span class="emphasis"><em>on</em></span>, the Decompiler infers a data-type for constants
	  it determines are likely pointers. In the basic heuristic,
          each constant is considered as an address, and if that address starts a known data or function element
          in the program, the constant is assumed to be a pointer.  The constants are treated like
	  any other source of data-type information, and the inferred data-types are freely propagated by
	  the Decompiler to other parts of the function.
	</p>
      </dd>
<dt>
<a name="AnalysisNanIgnore"></a><span class="term"><span class="bold"><strong>NaN operations</strong></span></span>
</dt>
<dd>
        <p>
          This option determines how the Decompiler treats floating-point <span class="bold"><strong>NaN</strong></span>
          (Not a Number) operations.  Many processors automatically perform NaN checks on the operands of
          floating-point instructions, and unless specifically configured, these show up in Decompiler output
          as <code class="code">NAN()</code> functional tokens.  Common floating-point source code operations, like
          <code class="code">&lt;</code>, <code class="code">&gt;</code>, and <code class="code">==</code> can generate <code class="code">NAN</code> tokens as a
          side effect, even if the original source code was not designed to handle NaN values, and the
          tokens can clutter the output.
        </p>
        <p>
          The user can optionally configure some or all of the NaN operations to be ignored, meaning that
          inputs to the NaN operation are <span class="emphasis"><em>assumed</em></span> to be valid floating-point values and the
          <code class="code">NAN</code> function is removed, replacing it with the value: <span class="bold"><strong>false</strong></span>.
          The possible settings are:
          </p>
<div class="informalexample">
            <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Ignore none</strong></span> - No NaN operations are removed</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Ignore with comparisons</strong></span> - NaN operations associated with comparisons are removed</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Ignore all</strong></span> - All NaN operations are removed</li>
</ul></div>
	  </div>
<p>
          The Decompiler considers a NaN operation to be associated with a floating-point comparison if they both
          can be considered boolean clauses of the same <span class="bold"><strong>if</strong></span> condition.
        </p>
      </dd>
<dt>
<a name="AnalysisForLoops"></a><span class="term"><span class="bold"><strong>Recover -for- loops</strong></span></span>
</dt>
<dd>
	<p>
	  When toggled <span class="emphasis"><em>on</em></span>, the Decompiler attempts to pinpoint
	  variables that control the iteration over specific loops in the function body.
	  When these <span class="emphasis"><em>loop</em></span> variables are discovered, the loop is
	  rendered using a standard <span class="bold"><strong>for</strong></span> loop header
	  that contains an initializer statement, condition, and iterating statement.
	  </p>
<div class="informalexample">
	    <code class="code">for (iVar2 = 10; iVar2 &lt; len; iVar2 = iVar2 + 1) { ...</code>
	  </div>
<p>
	</p>
	<p>
	  When toggled <span class="emphasis"><em>off</em></span>, the loop is displayed using
	  <span class="bold"><strong>while</strong></span> syntax, with any initializer and
	  iterating statements mixed in with the loop body or preceding basic blocks.
	</p>
      </dd>
<dt>
<a name="AnalysisReadOnly"></a><span class="term"><span class="bold"><strong>Respect read-only flags</strong></span></span>
</dt>
<dd>
	<p>
	  When toggled <span class="emphasis"><em>on</em></span>, the Decompiler treats any values in memory
          marked <span class="emphasis"><em>read-only</em></span> as constant. If a read-only memory location is explicitly
	  referenced by the function being decompiled, it is considered to be unchanging, and the initial
	  value present in the Program is pulled into the data flow of the function as a constant.
	  Due to <span class="emphasis"><em>Constant Propagation</em></span> and other transformations, read-only memory
	  can have a large effect on Decompiler output.
	</p>
	<p>
           Typically, as part of the import process, Ghidra marks memory blocks as read-only if they
           are tagged as such by a section header or other meta-data in the original binary.
	   Users can actively set whether specific memory regions are considered read-only through the
	  <span class="emphasis"><em>Memory Manager</em></span>, and individual data elements can be marked
	  as <span class="emphasis"><em>constant</em></span> via the <span class="bold"><strong>Mutability</strong></span> setting
	  (see <a class="xref" href="DecompilerAnnotations.html#AnnoteMutability" title="Data Mutability">Data Mutability</a>). 
	</p>
      </dd>
<dt>
<a name="AnalysisExtendedPrecision"></a><span class="term"><span class="bold"><strong>Simplify extended integer operations</strong></span></span>
</dt>
<dd>
	<p>
	  This toggles whether the Decompiler attempts to simplify double precision arithmetic operations,
          where a single logical operation is split into two parts, calculating the high and low pieces
	  of the result in separate instructions.  Decompiler support for this kind of transform is currently
	  limited, and only certain constructions are simplified.
	</p>
      </dd>
<dt>
<a name="AnalysisPredicate"></a><span class="term"><span class="bold"><strong>Simplify predication</strong></span></span>
</dt>
<dd>
	<p>
	  When this option is active, the Decompiler simplifies code sequences containing
	  <span class="emphasis"><em>predicated</em></span> instructions. A predicated instruction is executed
	  conditionally based on a boolean value, the <span class="bold"><strong>predicate</strong></span>,
	  and a sequence of instructions can share the same predicate. The Decompiler merges the
	  resulting <code class="code">if/else</code> blocks that share the same predicate so that the condition is only
	  printed once.
	</p>
      </dd>
<dt>
<a name="AnalysisSplitStruct"></a><span class="term"><span class="bold"><strong>Split combined structure fields</strong></span></span>
</dt>
<dd>
	<p>
	  When this option is active, the Decompiler attempts to identify places in the code where multiple
	  fields of a structure data-type are being moved simultaneously with a single operation. Then it splits the
	  operation into multiple pieces so that the logical fields can be seen individually.
	  When this option isn't active, the Decompiler creates an artificial token to
	  represent the combined fields being written to or read from.
          </p>
<div class="informalexample">
	    <pre class="programlisting">
	      struct1._20_4_ = 0xff00ff00;  // Auto-generated name for assigning multiple fields at once
	        ...
	      struct1.a = 0xff00;           // The same assignment, after splitting
	      struct1.b = 0xff00;
	    </pre>
          </div>
<p>
	</p>
      </dd>
<dt>
<a name="AnalysisSplitArray"></a><span class="term"><span class="bold"><strong>Split combined array elements</strong></span></span>
</dt>
<dd>
	<p>
	  When this option is active, the Decompiler attempts to identify places in the code where multiple
	  elements of an array are being moved simultaneously with a single operation. Then it splits the
	  operation into multiple pieces so each element of the array can be seen individually.
	  When this option isn't active, the Decompiler creates an artificial token to
	  represent the combined elements being written to or read from.
          </p>
<div class="informalexample">
	    <pre class="programlisting">
	      text._20_2_ = 0x4241;        // Auto-generated name for assigning multiple elements at once
	        ...
	      text[20] = 'A';              // The same assignment, after splitting
	      test[21] = 'B';
	    </pre>
          </div>
<p>
	</p>
      </dd>
<dt>
<a name="AnalysisSplitPointers"></a><span class="term"><span class="bold"><strong>Split pointers to combined elements</strong></span></span>
</dt>
<dd>
	<p>
	  This options affects when the Decompiler's splitting actions are applied. See
	  the discussion above about 
	  <a class="link" href="DecompilerOptions.html#AnalysisSplitStruct">Splitting Structure Accesses</a> and
	  <a class="link" href="DecompilerOptions.html#AnalysisSplitArray">Splitting Array Accesses</a>.
	  If this option is on, a split is performed whenever combined elements or combined
	  fields are copied.  In particular, either the read access, or the write access, or both,
	  can be through a pointer.
	  If this option is off, splitting is limited to copies between structures or arrays at fixed
	  locations, either at a global address, or on the local stack.
	</p>
      </dd>
<dt>
<a name="AnalysisInPlace"></a><span class="term"><span class="bold"><strong>Use in-place assignment operators</strong></span></span>
</dt>
<dd>
	<p>
	  When toggled <span class="emphasis"><em>on</em></span>, the Decompiler employs in-place assignment operators,
	  such as <code class="code">+=</code> and <code class="code">&lt;&lt;=</code>, in its output syntax.
	</p>
      </dd>
</dl></div>
    </div>
<p>
  </p>
</div>

<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="DisplayOptions"></a>Display Options</h2></div></div></div>
  
  <p>
    These options do not change the Decompiler's analysis but only affect how the results are presented.
  </p>
  <p>
    </p>
<div class="informalexample">
    <div class="variablelist"><dl class="variablelist">
<dt>
<a name="DisplayBackgroundColor"></a><span class="term"><span class="bold"><strong>Background Color</strong></span></span>
</dt>
<dd>
	<p>
	  Assign the background color for the Decompiler window.
	</p>
      </dd>
<dt>
<a name="DisplayBraceFormatting"></a><span class="term"><span class="bold"><strong>Brace Format for &lt;kind-of&gt; blocks</strong></span></span>
</dt>
<dd>
	<p>
          Choose how braces are placed after function declarations, or other kinds of code blocks in Decompiler output.
          Formatting can be controlled for:
          </p>
<div class="informalexample">
            <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>function blocks</strong></span> - the main function bodies</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>if/else blocks</strong></span> - blocks delineated by the <code class="code">if</code> and <code class="code">else</code> keywords</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>loop blocks</strong></span> - blocks delineated by the <code class="code">for</code>, <code class="code">do</code>, and <code class="code">while</code> keywords</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>switch blocks</strong></span> - blocks delineated by the <code class="code">switch</code> keyword</li>
</ul></div>
          </div>
<p>
          The different formatting options primarily control how the opening brace is displayed relative to the line containing
          the declaration or keyword starting the block.  The formatting options are:
          </p>
<div class="informalexample">
            <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Same line</strong></span> - opening brace placed on same line</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Next line</strong></span> - opening brace placed on the next line</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Skip one line</strong></span> - opening brace placed on line after a blank line</li>
</ul></div>
          </div>
<p>
	</p>
        <p>
          The "Same line" option is consistent with K &amp; R code formatting style.  The "Next line" option is consistent with
          the Allman formatting style.
        </p>
      </dd>
<dt>
<a name="DisplayColorDefault"></a><span class="term"><span class="bold"><strong>Color Default</strong></span></span>
</dt>
<dd>
	<p>
	  Assign the color to any characters emitted by the Decompiler that do not fall into one of token types
	  listed below. This includes delimiter characters like commas and parentheses as well as various <span class="emphasis"><em>operator</em></span>
	  characters.
	</p>
      </dd>
<dt>
<a name="DisplayTokenColor"></a><span class="term"><span class="bold"><strong>Color for &lt;token&gt;</strong></span></span>
</dt>
<dd>
	<p>
	  Assign colors to the different types of language tokens emitted by the Decompiler.
	  These include:
          </p>
<div class="informalexample">
            <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc"><span class="bold"><strong>Comments</strong></span></li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Constants</strong></span> - including integer, floating-point, character, and string</li>
<li class="listitem" style="list-style-type: disc"><span class="bold"><strong>Functions names</strong></span></li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Globals</strong></span> - names of variables with global scope</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Keywords</strong></span> - reserved names in the language being emitted</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Parameters</strong></span> - names of function input variables</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Types</strong></span> - names of data-types in variable declarations and casts</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Variables</strong></span> - names of local variables</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Special</strong></span> - volatile variables and other special symbols</li>
</ul></div>
	  </div>
<p>
	</p>
      </dd>
<dt>
<a name="DisplayCurrentHighlight"></a><span class="term"><span class="bold"><strong>Color for Current Variable Highlight</strong></span></span>
</dt>
<dd>
	<p>
	  Assign the background color used to highlight the token currently under the cursor in a Decompiler window.
	</p>
      </dd>
<dt>
<a name="DisplayFindHighlight"></a><span class="term"><span class="bold"><strong>Color for Highlighting Find Matches</strong></span></span>
</dt>
<dd>
	<p>
	  Assign the background color used to highlight characters matching the current <span class="emphasis"><em>Find</em></span> pattern
	  (see <a class="xref" href="DecompilerWindow.html#ActionFind" title="Find...">Find...</a>).
	</p>
      </dd>
<dt>
<a name="DisplayCommentIndent"></a><span class="term"><span class="bold"><strong>Comment line indent level</strong></span></span>
</dt>
<dd>
	<p>
	  Set the number of characters that comment lines are indented within Decompiler output. This applies only
	  to comments within the body of the function being displayed.  Comments at the head of the function
	  are not indented.
	</p>
      </dd>
<dt>
<a name="DisplayCommentStyle"></a><span class="term"><span class="bold"><strong>Comment style</strong></span></span>
</dt>
<dd>
	<p>
	  Set the language syntax used to delimit comments emitted as part of Decompiler output. For C and Java,
	  the choices are <code class="code">/* C style comments */</code> and <code class="code">// C++ style comments</code>.
	</p>
      </dd>
<dt>
<a name="DisplayDisableCasts"></a><span class="term"><span class="bold"><strong>Disable printing of type casts</strong></span></span>
</dt>
<dd>
	<p>
	  Set whether the syntax for <span class="emphasis"><em>type casts</em></span> is emitted in Decompiler output.
	  If this is toggled on, type cast syntax is never displayed, even when rules of the language
	  require it. So individual statements may no longer be formally accurate.
	</p>
      </dd>
<dt>
<a name="CommentOptions"></a><span class="term"><span class="bold"><strong>Display &lt;kind-of&gt; Comments</strong></span></span>
</dt>
<dd>
	<p>
	  Set whether a specific type of comment should be incorporated into Decompiler output. 
	  Each type has its own toggle and can be individually included or excluded from Decompiler output. 
	  </p>
<div class="informalexample">
	    <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">
		<span class="bold"><strong>EOL</strong></span>
	      </li>
<li class="listitem" style="list-style-type: disc">
		<span class="bold"><strong>PLATE</strong></span> - Whether plate comments <span class="emphasis"><em>within the body of the function</em></span> are displayed
	      </li>
<li class="listitem" style="list-style-type: disc">
		<span class="bold"><strong>POST</strong></span>
	      </li>
<li class="listitem" style="list-style-type: disc">
		<span class="bold"><strong>PRE</strong></span>
	      </li>
</ul></div>
	  </div>
<p>
	  A comment's type indicates how it is placed within a Listing window, not how it is placed in
	  a Decompiler window.  All comments within the body of the function are displayed in the same way
	  by the decompiler, regardless of their type (see the discussion in <a class="xref" href="DecompilerAnnotations.html#AnnoteComments" title="Comments">Comments</a>).
	</p>
      </dd>
<dt>
<a name="DisplayHeaderComment"></a><span class="term"><span class="bold"><strong>Display Header comment</strong></span></span>
</dt>
<dd>
	<p>
	  Toggle whether the Decompiler emits comments at the head (before the beginning) of a function.
	  The header is built from Plate comments placed at the <span class="emphasis"><em>entry point</em></span> of the
	  function (see the discussion in <a class="xref" href="DecompilerAnnotations.html#AnnoteComments" title="Comments">Comments</a>).
	  The inclusion of other Plate comments is controlled by the <span class="bold"><strong>Display PLATE comments</strong></span> toggle, described above. 
	</p>
      </dd>
<dt>
<a name="DisplayLineNumbers"></a><span class="term"><span class="bold"><strong>Display Line Numbers</strong></span></span>
</dt>
<dd>
	<p>
	  Toggle whether line numbers are displayed in any Decompiler window.  If toggled
	  on, each Decompiler window reserves space to display a numbers down the left
	  side of the window, labeling each line of output produced by the Decompiler.
	  Line numbers are associated with the window itself and are not formally part of
	  the Decompiler's output.
	</p>
      </dd>
<dt>
<a name="DisplayNamespaces"></a><span class="term"><span class="bold"><strong>Display Namespaces</strong></span></span>
</dt>
<dd>
	<p>
	  Control how the Decompiler displays namespace information associated
	  with function and variable symbols. The possible settings are:
	  </p>
<div class="informalexample">
	    <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">
		<span class="bold"><strong>Minimally</strong></span> - Display the minimal path that distinguishes the symbol 
	      </li>
<li class="listitem" style="list-style-type: disc">
		<span class="bold"><strong>Always</strong></span> - Always display the entire namespace path
	      </li>
<li class="listitem" style="list-style-type: disc">
		<span class="bold"><strong>Never</strong></span> - Never display the namespace path
	      </li>
</ul></div>
	  </div>
<p>
	</p>
	<p>
	  The <span class="bold"><strong>Minimally</strong></span> setting, which is the default, will only emit the portion
	  of the namespace path necessary to distinguish the symbol from other symbols with the same base name used
	  by the function, or if a portion of the path is completely outside the function's scope.
	</p>
	<p>
	  The <span class="bold"><strong>Never</strong></span> setting never displays any of the namespace path under any
	  circumstances and may produce output that is ambiguous and doesn't formally parse.
	</p>
      </dd>
<dt>
<a name="DisplayWarningComments"></a><span class="term"><span class="bold"><strong>Display Warning comments</strong></span></span>
</dt>
<dd>
	<p>
	  Toggle whether Decompiler generated <span class="emphasis"><em>WARNING</em></span> comments are displayed as part
	  of the output. The Decompiler generates these comments, independent of those laid down by users, to
	  indicate unusual conditions or possible errors (see <a class="xref" href="DecompilerAnnotations.html#CommentWarnings" title="Warning Comments">Warning Comments</a>). 
	</p>
      </dd>
<dt>
<a name="DisplayFont"></a><span class="term"><span class="bold"><strong>Font</strong></span></span>
</dt>
<dd>
	<p>
	  Set the typeface used to render characters in any Decompiler window. Indentation is generally clearer
	  using a monospaced (fixed-width) font, but any font available to Ghidra can be used.  The size of
	  the font can also be controlled from this option.
	</p>
      </dd>
<dt>
<a name="DisplayIntegerFormat"></a><span class="term"><span class="bold"><strong>Integer format</strong></span></span>
</dt>
<dd>
	<p>
	  Set how integer constants are formatted in the Decompiler output.
	  The possible settings are:
	  </p>
<div class="informalexample">
	    <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">
		<span class="bold"><strong>Force Hexadecimal</strong></span> - Always use a hexadecimal representation
	      </li>
<li class="listitem" style="list-style-type: disc">
		<span class="bold"><strong>Force Decimal</strong></span> - Always use a decimal representation
	      </li>
<li class="listitem" style="list-style-type: disc">
		<span class="bold"><strong>Best Fit</strong></span> - Select the most <span class="emphasis"><em>natural</em></span> representation
	      </li>
</ul></div>
	  </div>
<p>
	  For <span class="bold"><strong>Best Fit</strong></span>, a representation is selected based on how
	  close it is to either a <span class="emphasis"><em>round</em></span> decimal value (10, 100, 1000, etc.) or
	  a round hexadecimal value (0x10, 0x100, 0x1000, etc.)
	</p>
      </dd>
<dt>
<a name="DisplayMaxChar"></a><span class="term"><span class="bold"><strong>Maximum characters in a code line</strong></span></span>
</dt>
<dd>
	<p>
	  Set the maximum number of characters in a line of code emitted by the Decompiler before a line break
	  is forced.  The Decompiler will not split an individual token across lines. So line breaks frequently
	  will come before the maximum number of characters is reached, and technically a single token can
	  extend the line beyond the maximum.
	</p>
      </dd>
<dt>
<a name="DisplayIndentLevel"></a><span class="term"><span class="bold"><strong>Number of characters per indent level</strong></span></span>
</dt>
<dd>
	<p>
	  Set the amount of indenting used to print statements within a nested scope in the
	  Decompiler output.  Each level of nesting (function bodies,
	  loop bodies, <span class="bold"><strong>if/else</strong></span> bodies, etc.)
	  adds this number characters.
	</p>
      </dd>
<dt>
<a name="DisplayNull"></a><span class="term"><span class="bold"><strong>Print 'NULL' for null pointers</strong></span></span>
</dt>
<dd>
	<p>
	  Set how null pointers are displayed in Decompiler output.  If this is toggled
	  on, the Decompiler will print a constant pointer value of zero (a <span class="bold"><strong>null</strong></span> pointer)
	  using the special token <code class="code">NULL</code>.  Otherwise the pointer value is represented with the '0' character,
	  which is then cast to a pointer.
	</p>
      </dd>
<dt>
<a name="DisplayConvention"></a><span class="term"><span class="bold"><strong>Print calling convention name</strong></span></span>
</dt>
<dd>
	<p>
	  Set whether the <span class="emphasis"><em>calling convention</em></span> is printed as part of the function
	  declaration in Decompiler output. If this option is turned on, the name of the calling convention
	  is printed just prior to the return value data-type within the function declaration.  All functions
	  in Ghidra have an associated calling convention (or prototype model) that is used during
	  Decompiler analysis (see the discussion in <a class="xref" href="DecompilerConcepts.html#ConceptPrototypeModel" title="Prototype Model">Prototype Model</a>).
	</p>
      </dd>
</dl></div>
    </div>
<p>
  </p>
</div>

<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ProgramOptions"></a>Program Options</h2></div></div></div>
  
  <p>
    Changes to these options affect only the Decompiler and only for
    the current Program being analyzed.
  </p>
  <p>
    </p>
<div class="informalexample">
    <div class="variablelist"><dl class="variablelist">
<dt>
<a name="OptionProtoEval"></a><span class="term"><span class="bold"><strong>Prototype Evaluation</strong></span></span>
</dt>
<dd>
	<p>
	  Sets the calling convention (prototype model) used when decompiling a function where
	  the convention is not known; i.e., marked as <span class="bold"><strong>unknown</strong></span>.  Many architectures have multiple
	  calling conventions, <span class="bold"><strong>__stdcall</strong></span>, <span class="bold"><strong>__thiscall</strong></span>, etc.
	  (see the discussion in <a class="xref" href="DecompilerConcepts.html#ConceptPrototypeModel" title="Prototype Model">Prototype Model</a>).  
	</p>
      </dd>
</dl></div>
    </div>
<p>
  </p>
</div>
<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ExtensionOptions"></a>Specification Extensions</h2></div></div></div>
  
  <p>
    This entry displays elements from the Program's <span class="emphasis"><em>compiler specification</em></span> and
    <span class="emphasis"><em>processor specification</em></span> and allows the user to add or remove
    <span class="bold"><strong>extensions</strong></span>, including prototype models, call-fixups, and
    callother-fixups.
  </p>
  <p>
    Every program has a <span class="emphasis"><em>core</em></span> set of specification elements,
    loaded from the <a class="xref" href="DecompilerConcepts.html#ConceptSpecification" title="SLEIGH Specification Files">SLEIGH Specification Files</a>, that cannot
    be modified or removed. Extensions, however, can be added to this core specification. Any extension
    imported from this dialog is directly associated with the active Program and is stored permanently
    with it.
  </p>
  <p>
    Users can change or reimport an extension if new information points to a better definition.
    Users have full control over an extension, and unlike a core element, can tailor it specifically
    to the Program.  
  </p>
  <p>
    This options entry presents a table of all specification elements.
    Each element, whether core or an extension, is displayed on a separate row with three columns:
    </p>
<div class="informalexample">
      <div class="itemizedlist"><ul class="itemizedlist compact" style="list-style-type: none; ">
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>Extension Type</strong></span> - indicating the type of element</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>Name</strong></span> - showing the formal name of the element</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>Status</strong></span> - indicating whether the element is core or an extension</li>
</ul></div>
    </div>
<p>
    The core elements of the specification have a blank Status column, and any extension
    is labeled either as <span class="bold"><strong>extension</strong></span> or <span class="bold"><strong>override</strong></span>.
  </p>
  <div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
<a name="ExtendTypes"></a>Extension Types</h3></div></div></div>
    
    <p>
      Each of the element types described here represents an XML tag of the same name, which, if
      present in the table, must either be in the <span class="emphasis"><em>compiler specification</em></span> file,
      the <span class="emphasis"><em>processor specification</em></span> file, or provided to Ghidra as an
      import document.
      </p>
<div class="informalexample">
	<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><span class="bold"><strong>prototype</strong></span></span></dt>
<dd>
	    <p>
	      This element is a named <a class="xref" href="DecompilerConcepts.html#ConceptPrototypeModel" title="Prototype Model">Prototype Model</a> that holds a specific set
	      of parameter-passing details. It
	      can be applied to individual functions by name, typically via the <span class="bold"><strong>Calling Convention</strong></span> menu
	      in the <a class="ulink" href="help/topics/FunctionPlugin/Variables.htm#Edit_Function" target="_top">Function Editor Dialog</a>.
	      See the documentation on <a class="xref" href="DecompilerAnnotations.html#AnnotePrototype" title="Function Prototypes">Function Prototypes</a> for how they affect decompilation.
	    </p>
	    <p>
	      The XML <code class="code">&lt;prototype&gt;</code> tag always has a <span class="bold"><strong>name</strong></span> attribute
	      that defines the formal name of the prototype model, which must be unique across all models.
	      </p>
<pre class="programlisting">
&lt;prototype name="__stdcall" extrapop="unknown" stackshift="4"&gt;
  &lt;input&gt;
    &lt;pentry minsize="1" maxsize="500" align="4"&gt;
      &lt;addr offset="4" space="stack"/&gt;
    &lt;/pentry&gt;
  &lt;/input&gt;
  &lt;output&gt;
  ...
	      </pre>
<p>
	    </p>
	  </dd>
<dt><span class="term"><span class="bold"><strong>callfixup</strong></span></span></dt>
<dd>
	    <p>
	      This element is a Call-fixup, which can be used to substitute a specific p-code
	      sequence for CALL instructions during decompilation, as described in
	      <a class="xref" href="DecompilerAnnotations.html#AnnotePrototype" title="Function Prototypes">Function Prototypes</a>.
	    </p>
	    <p>
	      The <code class="code">&lt;callfixup&gt;</code> tag has a <span class="bold"><strong>name</strong></span>
	      attribute listing the formal name, which must be unique across all call-fixups.
	      </p>
<pre class="programlisting">
&lt;callfixup name="EH_prolog3"&gt;
  &lt;pcode&gt;
    &lt;body&gt;&lt;![CDATA&lt;
      EBP = ESP + 4;
      tmp = * EBP;
      ESP = ESP - tmp;
      ESP = ESP - 24;
    ]]&gt;&lt;/body&gt;
  &lt;/pcode&gt;
&lt;/callfixup&gt;
	      </pre>
<p>
	    </p>
	  </dd>
<dt><span class="term"><span class="bold"><strong>callotherfixup</strong></span></span></dt>
<dd>
	    <p>
	      This element is a Callother-fixup, which can be used to substitute a specific p-code
	      sequence for CALLOTHER p-code operations.  A CALLOTHER
	      is a black-box, or unspecified p-code operation (see <a class="xref" href="DecompilerConcepts.html#ConceptCallother" title="User-defined P-code Operations - CALLOTHER">User-defined P-code Operations - CALLOTHER</a>).
	    </p>
	    <p>
	      The <code class="code">&lt;callotherfixup&gt;</code> tag has a
	      <span class="bold"><strong>targetop</strong></span> attribute which lists the
	      name of the particular CALLOTHER operation it substitutes for.
	      </p>
<pre class="programlisting">
&lt;callotherfixup targetop="dynamicPush"&gt;
  &lt;pcode&gt;
    &lt;input name="amount"/&gt;
    &lt;body&gt;&lt;![CDATA[
      RSP = RSP + amount;
    ]]&gt;&lt;/body&gt;
  &lt;/pcode&gt;
&lt;/callotherfixup&gt;
	      </pre>
<p>
	    </p>
	  </dd>
</dl></div>
      </div>
<p>
    </p>
  </div>
  <div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
<a name="ExtendStatus"></a>Status</h3></div></div></div>
    
    <p>
      The Status column labels an element as either a core specification
      or an extension; it also gives an indication of whether the element
      is about to be installed or removed.
    </p>
    <p>
      With no changes pending, the column will show one of the three main values:
      </p>
<div class="informalexample">
	<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><span class="emphasis"><em>&lt;blank&gt;</em></span></span></dt>
<dd>
	    <p>
	      A blank Status column indicates that the element is a core part of the
	      specification, originating from one of the <span class="emphasis"><em>specification files</em></span>.
	      These elements cannot be changed or removed.
	    </p>
	  </dd>
<dt><span class="term"><span class="bold"><strong>extension</strong></span></span></dt>
<dd>
	    <p>
	      Indicates that the element is a program-specific extension that has been
	      added to the specification.
	    </p>
	  </dd>
<dt><span class="term"><span class="bold"><strong>override</strong></span></span></dt>
<dd>
	    <p>
	      Indicates that the element, which must be a <span class="bold"><strong>callotherfixup</strong></span>,
	      is an extension that overrides a core element with the same target.  The extension
	      effectively replaces the p-code injection of the core element with a user-supplied one.
	      If this type of extension is later removed, the core element becomes active again.
	    </p>
	  </dd>
</dl></div>
      </div>
<p>
    </p>
    <p>
      If the user has either imported additional extensions or selected an extension for removal but
      has not yet clicked the <span class="emphasis"><em>Apply</em></span> button in the Options dialog, the Status column
      may show one of the following values, indicating a pending change:
      </p>
<div class="informalexample">
	<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><span class="bold"><strong>install</strong></span></span></dt>
<dd>
	    <p>
	      Indicates a new extension that will be installed.
	    </p>
	  </dd>
<dt><span class="term"><span class="bold"><strong>remove</strong></span></span></dt>
<dd>
	    <p>
	      Indicates an extension that is about to be removed.
	    </p>
	  </dd>
<dt><span class="term"><span class="bold"><strong>replace</strong></span></span></dt>
<dd>
	    <p>
	      Indicates a new extension that will replace a current
	      extension with the same name.
	    </p>
	  </dd>
<dt><span class="term"><span class="bold"><strong>override pending</strong></span></span></dt>
<dd>
	    <p>
	      Indicates a new extension that will override a core element when
	      it is installed.
	    </p>
	  </dd>
</dl></div>
      </div>
<p>
    </p>
  </div>
  <div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
<a name="ExtendImport"></a>Importing a New Extension</h3></div></div></div>
    
    <p>
      The <span class="emphasis"><em>Import</em></span> button at the bottom of the
      <span class="bold"><strong>Specification Extensions</strong></span> pane allows the user to import one of the
      three element types, <span class="bold"><strong>prototype</strong></span>,
      <span class="bold"><strong>callfixup</strong></span>, or <span class="bold"><strong>callotherfixup</strong></span>,
      into the program as a new extension.
      The user must supply a properly formed XML document, as a file, that fully describes the new
      extension.  Clicking the <span class="emphasis"><em>Import</em></span> button brings up a File Chooser dialog,
      from which the user must select their prepared XML file.  Once <span class="emphasis"><em>Ok</em></span> is
      clicked, the file is read in and validated.  If there are any problems with the validation, or if
      the new extension's name collides with a core element, the import does not succeed and
      an error message will be displayed. Otherwise, the import is accepted, and the table is updated
      to indicate the pending change.
    </p>
    <p>
      The final change to the program, installing the new extension, will not happen until the
      <span class="emphasis"><em>Apply</em></span> button, at the bottom of the Options dialog, is clicked.
    </p>
    <p>
      The XML file describing the extension <span class="emphasis"><em>must</em></span> have one of the tags,
      <code class="code">&lt;prototype&gt;</code>, <code class="code">&lt;callfixup&gt;</code>, or <code class="code">&lt;callotherfixup&gt;</code>,
      as its single root element. Users can find numerous examples within the compiler
      and processor specification files that come as part of Ghidra's installation
      (see <a class="xref" href="DecompilerConcepts.html#ConceptSpecification" title="SLEIGH Specification Files">SLEIGH Specification Files</a>).
    </p>
    <p>
      In the case of <span class="bold"><strong>prototype</strong></span> and <span class="bold"><strong>callfixup</strong></span>
      elements, extensions cannot replace existing core elements, so the new extension <span class="emphasis"><em>must not</em></span>
      have a name that matches an existing core element.  If a new <span class="bold"><strong>callotherfixup</strong></span>
      extension has a targetop that matches a core element, the extension is automatically treated as an override.
    </p>
    <p>
      Existing extensions can be replaced simply by importing a new extension with the same name or targetop.
    </p>
  </div>
  <div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
<a name="ExtendRemove"></a>Removing an Extension</h3></div></div></div>
    
    <p>
      The <span class="emphasis"><em>Remove</em></span> button at the bottom of the <span class="bold"><strong>Specification Extensions</strong></span> pane allows
      the user to remove a previously installed extension.  A row from the table is selected first, which
      must have a Status of <span class="bold"><strong>extension</strong></span> or <span class="bold"><strong>override</strong></span>.
      Core elements of the specification cannot be removed.
      Clicking the <span class="emphasis"><em>Remove</em></span> button brings up a confirmation dialog, and if
      <span class="emphasis"><em>Ok</em></span> is clicked, the selected extension is marked for removal.  The Status of the row
      changes to <span class="bold"><strong>remove</strong></span>, reflecting this.
    </p>
    <p>
      The final change to the program, removing the extension, will not happen until the
      <span class="emphasis"><em>Apply</em></span> button, at the bottom of the Options dialog, is clicked.
    </p>
    <p>
      If a <span class="bold"><strong>prototype</strong></span> or <span class="bold"><strong>callfixup</strong></span> is removed,
      all functions are checked to see if they have the matching calling convention or call-fixup set.
      A function with matching calling convention is changed to have the <span class="emphasis"><em>default</em></span> convention, which is always a core element.
      A function with matching call-fixup is changed to have no call-fixup.
    </p>
  </div>
</div>

</div></body>
</html>
